1. Field of the Invention
This invention relates to making electronic payments on the Internet, and more specifically to providing a secure electronic money proxy to enable unrestricted commerce on the Internet or similar network.
2. Description of the Background of the Invention
At a minimum, electronic payments involve transmissions between three parties, a consumer, a merchant, and any credit or money disbursing institution, e.g., a bank or a credit union, (creditor). In exchange or in payment for goods and/or services, the consumer gives or issues a non-cash electronic instrument or a money-proxy to the merchant. For the remainder of this document such an instrument will be referred to as a token. The token includes the money balance of the consumer and other identifying information. The creditor validates the token, by verifying that cash or credit backs it. The creditor's validation enables the merchant to release the goods and/or services purchased to the consumer.
It is possible for the consumers and merchants to engage in transactions without the creditor. However, in such two-party transactions the issuance of the token by the consumer will be synonymous with creating money. Such eventuality is not suitable for the merchant, because he or she will be asked to accept the token without any assurances as to its value. It is presumed that the merchant must be able to use this token either in further trade, e.g., to purchase replacement merchandise, or redeem it for generally accepted currency.
Another drawback to the two party transactions involving multiple uses or spending of the token is the current state of electronic encryption. It is not possible with today's encryption technology to guarantee transactional security.
Three party transactions, including the consumer, merchant, and creditor, must be considered the minimum number of participants needed for electronic payments. However, every electronic payment transaction may involve different consumers and merchants, each with a different creditor. Furthermore, such electronic payment transactions may allow several possible methods of payment.
An efficient transaction structure would require the introduction of a fourth party. This fourth party will validate every consumer's token, irrespective of which creditor the consumer uses or the type of payment instrument, e.g., credit or debit card, credit line, check, or cash, used to purchase the token. The fourth party ensures that the consumer's token does in fact have its stated cash value and thereby eliminates merchant concerns regarding the token monetary balance. Therefore the token may be easily accepted by the merchant, redeemed as cash, or used to make merchandise replacement purchases.
Developments in the electronic payment area may be divided into two categories:    1. The first category consists of those approaches that address a subset of a payment transaction but are not in themselves complete solutions. These make up the vast majority of electronic payment developments. An example of this category is best described in U.S. Pat. No. 5,987,140. This patent presents a method of secure communication between the consumer, merchant, and creditor where authorizations are passed from the creditor to the merchant and to the consumer. Another example of this category is described in U.S. Pat. No. 5,999,91, where probabilistic polling of the merchant is used to permit the creditor to obtain an approximation of the consumer's spending. Moreover, U.S. Pat. No. 6,035,402 describes the use of an electronic Certification of Authority, used to authenticate the identity of the consumer, merchant, and/or creditor.    2. The second category of developments consists of those developments that may be considered complete solutions, designed to conclude a transaction between the consumer and the merchant from initiation or contract to completion or sale. An example of such approach is described in U.S. Pat. No. 5,952,638. This patent describes an electronic transaction initiated by a consumer who transmits a request for payment information to a merchant. The merchant's response is authenticated, after which the consumer generates an electronic payment. This electronic payment is then forwarded to the merchant as payment for the goods and/or services.
The complete solutions category of approaches can in turn be subdivided into solutions implemented exclusively using software and solutions requiring special hardware, e.g., smart cards, to operate. The special hardware is generally designed such that neither the merchant nor consumer can access or modify information stored on the hardware. An example of such hardware based electronic payment invention is described in U.S. Pat. No. 6,061,664. In that patent, a consumer can communicate with the merchant and conclude a transaction with a payment. However, such transaction requires specialized hardware including a smart card and a phone or voice communication device.
An example of a solution implemented using exclusively software is described in U.S. Pat. No. 6,029,150. In that patent, each consumer is burdened by an obligation to maintain an account with at least one of several agents. The consumer receives a price quote from a merchant, authenticates it, and sends that quote to an agent. The merchant must have an account with that agent. The agent then in turn issues an authenticated token to the consumer. The consumer then forwards all or part of that token to the merchant as payment.
The software solutions may permit exchange of the tokens between the consumers and merchants. The tokens can be stored, retrieved, and exchanged multiple times between the consumers and merchants to pay for the goods and services. In other words, the multi-use token system mimics the characteristics associated with the use of physical cash. Alternatively, tokens may be used no more than once and thereafter modified or destroyed in a single-use token system. The complete software-based solutions are further categorized into real time and non-real time token systems.
The non-real time token systems include electronic verification, negotiation, secure communication, authentication, payment instrument selection, etc. Although transactions can be concluded using these non-real time systems, the function of such systems is conceptually akin to making payments by check to the merchants who will wait three days for the check to clear before shipping or releasing the goods and services. Such systems lack “immediacy”. A good example of the non-real time token systems is described in U.S. Pat. No. 6,029,151. In this patent, charges incurred by the consumer are charged to his/her Internet Service Provider (ISP). This requires active participation of the consumer's ISP in the transaction. Settlement of charges using this method occurs only after the consumer receives his or her bill and pays it.
The real time token systems use the tokens to complete transactions in real-time. This is achieved by the consumer making a payment for goods and/or services through sending a token to the merchant; the merchant verifies and decrements the token; after which the goods or services purchased are released. The payments made through the real-time token systems are not any of the following actions: a negotiation to choose a form of payment, a method for verifying if the consumer is credit-worthy, a secure channel to communicate between transaction parties, a method to create a token. In their function, the real-time token systems are conceptually akin to cash transactions. Pay cash; Receive goods. While the goods may take time to ship or download over computer networks, the purchase transaction has, in essence, been consummated.
There exist various types of real-time token systems. First, there are those systems that depend on, or specify a particular protocol through the use of which electronic payments are transacted. An example of such protocol dependent real-time token systems is described in U.S. Pat. No. 6,061,665, which specifies a method of communication between the consumer and merchant having a dynamically negotiated payment protocol, message format, and suitable payment instrument.
Another type of real-time token system requires one or more parties in addition to the consumer, the merchant, and the creditor. Without these additional required parties, e.g., a Certificate Authority for issuing encryption/decryption keys, the transaction cannot be concluded.
Finally, another type of the real-time token system requires a priori arrangement in which the consumer or merchant would not otherwise engage in except for the purpose of prosecuting electronic payments. Such system may require that each merchant maintain an account with at least one of several creditors, or that each consumer maintain an account with every merchant with whom they transact, or that each consumer obtain encryption and decryption keys. An example of such real-time token system requiring a priori arrangement is described in U.S. Pat. No. 5,930,777. This patent describes a method for charging a consumer for the use of online information. The method requires the consumer to establish an account with at least one third party “banker” and to purchase “credit units” that have denominations that can be as small as fractions of one cent. The consumer may have accounts with more than one “banker” and may use these credit units to make on-line purchases.
In view of the foregoing discussion, it is clear that there is a need for a complete, protocol independent, real-time payment, single use, token system that is software based and does not depend on additional hardware. The system must be able to execute multiple consecutive transactions between the same consumer and a merchant, require one-time authentication, which will produce significant reductions in networking and computational overhead. The system should not require a Certificate Authority or additional agents beyond the consumer, merchant, and creditor-clearing server (representing a fourth party).